Electronic mail, or email as it is commonly referred to, is an invaluable resource in today's society. Businesses use email for client contact, transactions, advertising and other communication. Individuals use email to keep in contact with friends and family, for interacting with companies and online services, and for other communications. Email has largely replaced conventional mail, in many situations, due to the relatively rapid transfer of information available with email in comparison to conventional mail, in addition to the cost and convenience advantages offered by email.
The appeal and usefulness of email is diminished if the email recipient cannot trust that a message is from the person or business that it purports to be from. Typically the source address of an email is displayed on the recipient's email program to allow the user to see whom the email is supposed to be from. This display allows the recipient to decide whether to open the email if it is from a trusted source or to delete the email if it is from an unknown or untrustworthy source. However, like other computerized systems, email has been subjected to disruption and attack by computer hackers. Hackers are able to replace the source address of emails, thereby making an illegitimate email appear to be from a trusted source. This practice is referred to as email spoofing. The illegitimate emails are frequently fraudulent, which refers to unsolicited commercial advertisements (spoofed or not), often sent in mass mailings. The hackers replace the source address so the unsuspecting recipient believes that the email is from a known or trusted source and opens the email.
Importantly, spoofing enables perpetrators to leverage the trust a recipient has in a brand, an organization or a person to induce them to actions that may include sharing personal information, completing a financial transaction or downloading malicious software onto their computers
A common and dangerous form of spoofing, commonly called “phishing”, occurs when email that is purportedly from a trusted source is used to gather sensitive information on the recipient. The sensitive information is later be used to access the recipient's bank accounts or for other nefarious purposes. These email scams are typically criminal and frequently originate from outside the recipient's home country by criminal organizations or individuals.
Similarly, these unsolicited emails can contain computer virus and/or Trojan horses that can be used to leverage the machine to send anonymous malicious correspondence to others, to display false screens to gather data from the user, to capture keystrokes or data on the machine or to cause damage to the recipient's computer. In order to influence a recipient to open such an email, a hacker will substitute the actual source of the email with a trusted source name, such as the name of a well known brand or institution.
Security systems have been developed to combat email source address spoofing. A conventional email message transfer with source address authentication is illustrated by message flow chart 100 in prior art FIG. 1. In this transfer, an email message is generated by an Originator at 102. The Originator can be, for instance, a person generating one or more messages individually, or an electronic system for generating multiple emails. Typically a person generates the message using a web-based or client based email program on a personal computer. The message consists of a header and a body. The body contains the text information that the Originator wants to communicate to a Recipient. The header usually contains the email addresses of the Recipient and Originator, and can also contain a subject line, date and other information such as information used for authenticating the email. The Originator types the text into the body and enters the Recipient's email address and subject into the header. The Originator then pushes a “send” button in the email program which submits the message for delivery to a network operator, also referred to as a Sender, at step 104. After receiving the message from the Originator, the Sender electronically transmits the message, at step 106, generally through the Internet to a receiving network, referred to herein as the Receiver.
The appropriate Receiver is determined from a plurality of different Receivers using the Domain Name System (DNS) and the Recipients email address, obtained from the header of the message. The part of the email address following the “@” symbol is usually one or more domain name words that are easily remembered by people. The DNS is used for translating the word domain names into binary numerical identifiers that are used to electronically identify the corresponding Receiver. The DNS can also contain other information that is related to particular domain names. In the present example, at some point before passing along an email message to a Receiver, the Sender publishes appropriate authentication information for the Sender's domains and subdomains in the DNS at step 108.
The appropriate Receiver receives the message from the Sender at step 110 and discerns the domain or subdomain of the message's Sender from the header. The Receiver looks up the relevant domain or subdomain information from the Sender's DNS and authenticates the message using information published by the Sender in the DNS and information present in the message at step 112.
Sender Policy Framework (SPF) is one email authentication technique used for authenticating the sender of the email. In this technique, only certain hosts, or computer systems, are allowed to send emails for certain domain names. The authorized hosts for a given domain name are published in the DNS. Receivers check the DNS to make sure that the received message is from a host that is authorized for the given domain. Another email authentication technique is called DomainKeys Identified Mail (DKIM) and uses public key cryptography in verifying the source and content of emails.
The Receiver determines if the message passes the authentication processes applied at step 114. If the message fails authentication, the Receiver may apply a failure action to the message at step 116. If the message passes authentication, the Receiver may apply a delivery action to the message at step 120.
In this conventional message flow, the Receiver can choose from a variety of delivery actions. These options include: “delivery to inbox,” “deliver to spam folder,” or any other supported delivery mechanism that the Receiver chooses. The Recipient receives the message from the Receiver as determined by the Receiver's chosen delivery action in step 122. For example, the Recipient may receive an authenticated message in the inbox of his email program.
Prior systems have relied on the Receiver to decide what to do with a message based on the outcome of the authentication and other selection criteria as chosen by the Receiver. However, this reliance has yielded limitations based on a lack of reliable instructions or ‘policies’ from Senders that can relate authentication results to actions that can be safely enforced by the Receiver without either eliminating valid messages or allowing fraudulent messages undue safe passage.
Senders do not have an effective way to communicate policy information to Receivers that would enable them to indicate that their instructions can be trusted, pertain to multiple message characteristics, relate message characteristics to authentication or provide fine-grained policy on multiple authentication protocols.
Specifically, for the effective deployment of email authentication against the problem of domain spoofing, there are issues with existing authentication protocols that can lead Receivers to downplay the outcomes of authentication checks in determining subsequent actions taken on messages (e.g. decisions about whether or not to deliver them).
First, the mechanisms for Senders to efficiently communicate to Receivers the protocols they use for each domain are limited. Second, policies available for each protocol have generally been limited to broad instructions based solely on success and failure outcomes that do not include any additional message characteristics or interim stages of activity (e.g. testing) or all possible authentication outcomes.
For example, the DKIM protocol has an optional extension called Author Domain Signing Practices (ADSP) that allows a Sender to indicate whether, in conjunction with a DKIM signature for a given domain, the domain signs some or all of its messages, and it may request that the Receiver discard unsigned messages. However, this model does not allow the Sender to request fine grained policy actions (beyond the general “discard”), nor does it allow policy requests to be made in combination with other protocols, like SPF. Finally, it does not support a message handling reporting channel back to the Sender from the Receiver. SPF also has a policy mechanism that allows the Sender to request that messages that fail SPF are either rejected or “softfailed”; however, the problems with SPF make using this policy for any domains that actually send email highly problematic, since many legitimate emails will be rejected.
Third, Receivers have no independent means of verifying the currency and accuracy of any policy information published. If the Sender's email traffic includes important messages to customers of the Receiver, the Receiver seeks the ability to ensure information accuracy to prevent blocking these important messages (particularly on a large scale).
Fourth, messages legitimately authenticated by the Sender may have their authentication paths or signatures broken en route to the Receiver by forwarding systems and other interim networks, in association with the design of any one particular authentication protocol. These legitimate messages will not be accurately authenticated by the Receiver. In this last case, using multiple authentication methods is key to overcoming the issues with each authentication protocol, since the likelihood of multiple failures is quite small. However, current policy communication mechanisms work (in their limited way) for a single protocol only. Senders who use multiple authentication protocols may have special delivery instructions for the Receiver based the combination of those authentication outcomes, but there are no current mechanisms to communicate those combined policies.
In summary, if a Receiver had fine-grained, trusted instructions from the Sender regarding the characteristics of a message, the authentication protocols used and the specific action requested based on each used protocol, the Receiver could then enforce those requests and help prevent illegitimate mail from appearing in a Recipient's inbox and deliver valid messages with any desired privileges. In addition, the current policy communication schemes provide little feedback to the purported Sender regarding the handling of their messages. Without a structured mechanism for Receivers to report back the handling statistics to Senders, Senders are limited in their ability to “complete the loop” of information and understand if their messages are being properly authenticated and delivered, as well as who is attempting to send messages via their domains.
This structured mechanism that supports the important case of managing fine grained, trusted instructions for the effective enforcement of authentication against the problem of email domain spoofing, also enables a myriad of other security, delivery and display enhancements for email messages that are enabled by the effective communication and enforcement of detailed instructions about email traffic from a domain or host.
The present invention provides a highly advantageous message policy management system and method that are submitted to resolve the foregoing problems and concerns while providing still further advantages, as described hereinafter.